'''
安享智慧理财金融测试项目（功能+接口+自动化）


软件测试：通过手工或自动化的方式运行被测软件是否正常（看预期结果和实际结果是否一致）
测试目的：保障软件的质量（尽可能多的发现系统中的错误，证明软件存在问题）
测试体现形式：通过找出bug的形式验证质量
测试人员具备的素质：
    5个心：责任心、细心、耐心、专心、自信心
    2个能力：沟通力、表达力
    1个精神：团队协作精神
TODO 一、测试技能：

    1、功能测试：验证程序的功能是否满足需求
    2、自动化测试：使用代码或工具代替人工验证项目功能（功能测试）
    3、接口测试：针对模块与模块、系统与系统之间数据请求地址进行测试
    4、性能测试：模拟多人使用软件，查看服务器缺陷
    5、安全测试：评估软件的安全性，确保没有安全漏洞

TODO 二、就业方向：

    1、功能 + 接口        12-15k
    2、功能 + 性能
    3、功能 + web自动化
    4、接口 + 自动化      15-22k
    5、接口 + 性能        15k+

TODO 三、常见的测试分类

    1、按阶段（软件开发从无到有）划分
        ① 单元测试：测试程序源代码 - 开发自测 - UT，unit test
        ② 集成测试：又称接口测试，功能模块的组合测试，测试模块之间访问地址    -- 主流
        ③ 系统测试：测试整个系统，包括功能、兼容、文档等
        ④ 验收测试：分为内测（公司内部-产品经理可代表用户）、公测（玩家），使用不同人群来发掘项目缺陷
    2、按代码可见度划分
        ① 黑盒测试：看不见源代码（功能）     - 系统测试
        ② 灰盒测试：看见部分代码（接口）     - 集成测试
        ③ 白盒测试：看见全部代码（源代码）   - 单元测试

        注意：① 系统、黑盒测试，重点核心是功能测试
             ② 集成、灰盒测试，又称接口测试
             ③ 单元、白盒测试，对代码进行测试
             ④ 自动化测试，归属功能测试
             ⑤ 性能、安全测试，归属专项测试

TODO 四、测试策略

    冒烟测试：大规模执行测试之前，针对程序主功能进行验证，保证程序具备可测性
     《面试题：提测标准是什么？   -- 冒烟测试通过     ============================111
             测试之前要怎么做？  -- 冒烟测试
TODO 五、模型

    1、质量模型：提供测试设计的不同角度视野和验证方向
               学到：针对任何软件或硬件，测试要覆盖的方面
        - 软件质量模型（ISO/IEC25010）：
          ① 功能性
          ② 性能效率
          ③ 兼容性
          ④ 易用性
          ⑤ 信息安全  --以上为重点

          ⑥ 可靠性
          ⑦ 可维护性
          ⑧ 可移植性

    2、测试模型：
         ① W模型（双v模型）
               开发流程：用户需求    - 需求分析    - 概要设计    - 详细设计    - 编码|    - 集成    - 实施     - 交付
               测试流程：验收测试设计 - 系统测试设计 - 集成测试设计 - 单元测试设计 - 单元测试| - 集成测试 - 系统测试 - 验收测试
                   优点：测试伴随整个产品开发周期，测试对象不仅是程序还有需求、设计文档，测试接入较早，及早发现问题，降低修复成本
                   缺点：实施起来比较复杂，难度大，对于需求阶段和设计阶段的测试要求更高
                       《面试题：先做接口还是UI功能？   -- 先接口（ui功能指系统测试）     ============================222
         ② 瀑布模型
               可研与计划    -     需求分析    -      概要分析    -      详细设计      -       编码       -     软件测试    -     运行维护
                       可行性研究报告     需求规格说明书      概要设计文档           详细设计文档           程序           测试报告（用例、缺陷报告）
                       公司高层          产品经理           高级技术人员-架构人员    普通开发人员（程序员）  开发人员        测试人员
         ③ 敏捷开发模型：
               能够适用需求的变化，并能够给出快速的响应
               小步快跑
               ACP
TODO 六、测试工作流程

    1、需求分析：产品经理讲解需求
           前置：阅读需求分析文档，记录不明确之处
          （确保各部门需求理解一致，站在不同角度对需求文档查漏补缺）
           需求评审的目的：
               产品角度：需求能否真实表达用户的意愿
                       需求描述准确、严谨、易懂
               开发角度：对现有技术架构的影响
                       技术上是否可实现
                       技术上是否可验证
               测试角度：是否有价值（满足用户的要求）
                       颗粒度的大小及测试成本
                       需求是否可验证
    2、计划编写：测什么、谁来测、怎么测（目标及范围、人员进度安排、测试策略、测试所需的运行环境、测试工具）
           编写思路【扩展】
               制定一个简易模板（word），列出计划和方案的核心要素
               根据多级标题进行编制
               每个标题中的具体内容（正文）可以借鉴需求文档、设计文档、有历史测试计划和方案的文档
               找原有计划与方案进行修改，修改为属于自己项目的内容
               可以找相关人员进行评审，最后进行完善修改
    3、解析API文档：
           目的：提取接口测试点
           关注：
                11、单接口：
                      请求：
                          请求方法
                          请求path
                          请求信息头类型
                          请求参数/请求体（类型、是否必填、含义）
                      响应：
                          响应状态码
                          响应数据
                12、业务接口：接口与接口之间的依赖关系
    3、用例设计：设计执行测试的文档
    4、用例执行：执行测试文档
    5、缺陷管理：提交、修复（开发）、验证、关闭
    6、测试报告：测试背景、测试目标、测试过程、缺陷设计、缺陷分析、测试总结

TODO 七、测试用例及方法

    1、用例：用户使用的案例（是否能开机？验证内存？验证屏幕？检查运行速度）
       测试用例：执行测试时，使用的案例
    2、作用：
         防止漏测
         实施测试的标准
    3、格式 -- 八大要素：
        用例编号（项目模块编号）、用例标题（预期结果+操作步骤）、模块/项目、优先级、前置条件、测试步骤、测试数据、预期结果|、实际结果
    4、如何设计：不同场景有不同的设计方法
         ① 等价类划分法：穷举场景
               - 适用场景：大量数据测试输入，无法穷举测试
               有效：取一个即可
               无效：取一个即可

         ② 边界值分析法：限定边界规则
               - 适用场景：需要处理数值输入，且数值有明确范围限制

         ③ 判定表法：多条件依赖关系
                 - 适用场景：多个条件，多个结果，条件之间有组合关系，条件和结果之间有依赖（制约）关系
                 条件组合较少的（4个条件以下）
                 正交表和因果图（4个条件以上）

         ④ 场景法：项目业务用例（优先考虑，重点）
                  - 适用场景：在测试后期，对于整个系统的模块功能进行全部的组合测试
                  测试用例，首先设计业务用例，其次设计单功能

         ⑤ 错误推测法：经验推测系统可能出现的问题
                根据经验列举可能出现的问题清单-根据清单分析问题可能原因-推测发现缺陷
                场景：时间紧任务量大（没有时间写用例），提取当前项目中核心模块（出现问题较多）进行验证测试
                     时间宽裕，将原有模块（存在问题较多）进行再次细分测试

    5、验证码错误：为空、正确、错误、过期
TODO 缺陷
1、定义：软件在使用过程中存在的任何问题，简称Bug
2、判定标准：
     ① 少功能
     ② 功能实现错误
     ③ 多功能
     ④ 隐性功能错误
     ⑤ 不易使用
3、缺陷产生的原因：
     ① 需求阶段：需求理解不到位
     ② 设计阶段：设计文档有问题
     ③ 编码阶段：代码有问题
     ④ 运行阶段：软硬件系统本身故障导致软件缺陷
4、缺陷的生命周期：需求规格说明、设计、编码、测试、故障分类、故障隔离、故障解决
5、类型：功能错误、界面UI错误（前端）、兼容性（前端）、数据、易用性、改进建议、架构
6、核心内容：缺陷id、缺陷标题、缺陷状态、优先级、模块、缺陷描述、附件（图片、日志）
               缺陷id：bug_001
               标题：操作数据描述+预期+实际
                    -输入4位自然数验证qq，预期结果：验证失败，提示必须6-10位自然数，实际结果：验证通过
               缺陷状态：new
               优先级：P2
               模块：qq
               缺陷描述：[前置]
                           1、打开qq界面
                       [步骤]
                           1、输入qq：1234
                           2、点击验证
                       [预期]
                          不通过，提示：qq号应在6-10位自然数
                       [实际]
                          合格
7、缺陷跟踪流程：
      描述开发和测试如何配合处理bug
      流程：测试处理状态：new     第一次创建
                      closed  关闭
                      reopen  激活/重新打开
           开发处理状态：rejected       拒绝
                      inprogress     处理中
                      delay/postpone 延迟修复
                      fixed          已修复

           填写缺陷（测试）
           分配缺陷
           修改缺陷（开发）
           回归测试（测试）
           关闭缺陷（测试）
8、缺陷编写：
      ① 缺陷报告编号
      ② 严重程度（S1-主功能   S2-次要功能   S3-易用性、界面    S4-建议性问题）
                 P0-正向业务 P1-逆向业务   P2-逆向业务的单功能
           描述给产品，缺陷对于整个软件的破坏程度
      ③ 缺陷优先级（Priority0-24h内解决   Priority1-发布前必须修复   Priority2-可以在下一个版本中修复）
             描述开发修复缺陷的先后次序
      ④ bug类型（代码错误、兼容性问题、设计缺陷、性能问题）
      ⑤ 缺陷状态（New-新建   Open-打开  Closed-关闭  Postponed-延期   拒绝）
            描述缺陷的生命周期
         《面试题：怎么判定严重程度？   -- 分清主次功能/用例里的优先级P0，则是s1     ============================222
         《面试题：怎么判定功能错误属于前端还是后端bug？   -- 抓包（把前端发送给后端的所有信息全部拦截，抓包的核心是检查请求和响应的数据是否正确）     ============================222
                                                      请求操作正确，后端无响应（后端）/请求错误（前端）/请求正确，响应正常，显示内容不正常（前端）
         《面试题：当发现bug时，首先需要做什么？   -- 确认bug可复现（有些bug是偶发的），同时确认是否手误     ============================222
9、提交前需要确认：
      ① bug是否可重现
           《面试题：出现不可复现的bug怎么办？   --     ============================222
               -- 经过多次复现后，还是没出现，此时在本地记录当前的问题
                  回顾当时操作的流程及测试环境的配置要求，确认是否由于操作失误或环境临时故障引起（测试步骤、测试账号、测试网络、测试环境）
                  请开发协助查找当前测试模块是否有对应的日志信息（日志的位置可以问开发）
                  再考虑换一套环境（换个电脑或环境），查看是否复现上述问题，可以借助抓包工具、数据库
                  在后续版本中测试，关注是否还会出现上述问题
                  在后续版本再次出现，需要开发协助打印日志进行定位分析，同时测试需要提交bug
      ② bug是否唯一性：一个缺陷上报一个问题
      ③ bug是否规范性：符合公司或项目要求（信息准确、游戏界且是真是特定的、描述简洁易懂、描述缺陷过程有条件，有先后顺序） -准确、具体、简洁易懂、次序清晰
10、抓包：抓客户端发送给服务器的数据包或服务器响应客户端的数据包

TODO it行业常见岗位

     ① 前端：写http页面展示（传递消息，并把返回的信息展示在页面上）
     ② 后端：服务程序（实现前端返回信息的功能）
     ③ 测试：找缺陷
     ④ ui： 设计http页面上的图（美工）
          user interface，用户操作界面
     ⑤ 运维：管理维护服务器（安装软件项目的电脑）
     ⑥ 产品：梳理需求，设计原型图（仿真图）
     ⑦ 运营：上线运营策划、推广
'''